During development and testing of an embedded computer system, especially an embedded microprocessor-based computer system, it is normally necessary to connect the system to a host computer so that an engineer can debug the embedded system. Debugging software on the host computer provides access by the engineer into the embedded system. Typically, the engineer uses the host computer and debugging software to set break points which stop threads of execution on the target embedded system, monitor registers in the target, monitor memory states and monitor input and output data. The engineer may also restart threads that have been previously stopped and perform a variety of other tasks including rebooting the target computer using the host.
Although in normal operation the embedded system may be virtually self-sufficient in that it does not in normal use need to perform input/output, it may be necessary during debugging for such input/output to be performed. Examples of this are displaying messages at the host, reading characters from the host keyboard or reading data from a file stored on the host.
Similar situations requiring input/output may occur where an embedded system is sold to an end user and the end user needs to customize the embedded system, for example writing information into programmable read only memory in the embedded system.
Embedded systems may contain more than one application, for instance stored in a read only memory or downloaded over a link, at run-time. An example of the latter is a satellite transmission link. Each such application may need to perform input/output of data to the host computer during debugging. Furthermore, applications may be interconnected so that one application that is executing may, at a virtually arbitrary point in time, cause another application to start executing. Although it is possible to provide input/output libraries during the construction of each application, such libraries, and as a result the protocol implemented by the application for input/output, may differ between applications.
It is proposed in a related application to provide a dynamically loaded library containing routines necessary for communication. Such a library may additionally or alternatively include other routines, for example subroutines that allow hardware bugs discovered during debugging to be masked or worked around. A mechanism is also proposed in a related application to allow an application to locate the dynamic library by means of the stack of an exception handler for that application.
Typically, each application may be built individually, with a linker dynamically determining the addressable locations used for protocol implementation. If there is more than one application needing to access the library, the host will not be able to determine easily which memory locations should be used at a particular point in time. It would of course be possible to arrange a system which reserved locations in memory for protocol use but this requires application developer intervention regarding the input/output implementation.
As used herein, the term ‘digital signal processor’ includes microprocessors' in general and other like digitally operating processing devices.
It is accordingly a primary object of the present invention to at least partially overcome the difficulties of the prior art.